3 



REMARKS: 



10 



15 



20 



25 



30 



Claims 1-19 are active in the application. 

The specification has been amended to correct grammatical errors. No new matter 
has been added. 

Claims 1-19 were rejected as being unpatentable over US patent 6,253,980 to 
Murakami et al. in view of US patent application 2002/0022979 to Whipp et al. These 
rejections are traversed on the grounds that (1) Murakami et al. does not teach that an 
access controller in the cars can invalidate a digital key, (2) neither Murakami et al nor 
Whipp et al. teach or suggest the use of a digital key. Both Murakami et al. and Whipp et 
al. instead rely on a user ID authenticated by a central computer in data communication 
with the car. 

The present invention provides a rental car management system that does not 
require a data link between the rental cars and a central computer (see page 2, lines 15-17 
of present application). This feature greatly reduces the cost and complexity of the 
present system compared to systems requiring such data links (e.g. Murakami et al. and 
Whipp et al.). In the present invention, a client obtains a smart card or the like with a 
digital key. The digital key contains encoded information that enables the client to access 
the car. The digital key does not need to be authenticated by a central computer. The 
digital key is generated by the central computer, and the key includes encoded 
information that indicates the car ED, client ID, date and time of the rental and the like. 
An access control device 14 in the rental car reads the digital key and authenticates the 
digital key without any communication to the central computer. Authentication is based 
on a digital signature provided by the central computer (see page 6, lines 6-8). When the 
rented car is returned, the access control device changes the digital key to indicate it is 
invalidated. The client submits this invalidated digital key to the central computer to 
confirm that the car has been successfully returned. The entire process is secure and does 
not require a data link between the central computer and the rental car. 

The Office Action asserts that Murakami et al. teaches that the rental cars each 
have a means to invalidate a digital key. This is completely erroneous. Murakami et al. do 
not teach or suggest such a feature. Murakami et al rely on a data link between the rental 
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cars and a central computer (referred to as a "central facility'') for validation. When a 
client wishes to rent a car, the client presents an ID card to the car, which communicates 
with the central computer for validation. The car has no ability to change the data (ID) 
presented by the client, and in fact has no need to change this data because the central 
computer performs all the validation and authorization remotely through the data link 
(see col. 12, lines 36-67 and col. 11, lines 25-67). Moreover, Murakami et al. is silent 
with regards to the de-authorization or invalidation procedure for returning a car. 
Murakami et al. relies upon the central computer for authorization, and therefore provides 
no suggestion to use the car for de- authorization or invalidation of a user ID. Columns 6 
and 7, identified by the Examiner as teaching "each of said fleet of cars has a means to 
invalidate a digital key", in fact teach nothing of the sort. Columns 6 and 7 instead teach 
car selection (based on travels itinerary) and time/distance allocation. Hence, the 
rejections of claims 1-10, based on this erroneous interpretation of Murakami et al., must 
be withdrawn. 

As implied by the Examiner, Whipp et al. also fail to teach that each car can have 
a means for invalidating a digital key (e.g. paragraph 0053 of Whipp et al. lacks any 
suggestion of an invalidation mean). Hence, Whipp et al. cannot make up for the 
deficiencies of the Murakami et al reference. No possible combination of Murakami et al. 
and Whipp et al could include in the car the feature of a means for invalidating a digital 
key. 

Furthermore, since Murakami et al. relies on validation of a client ID by a central 
computer, Murakami et al. does not use a "digital key" as it is defined in the present 
invention. A "digital key" in the present invention is digital data that can be used to 
access the car without subsequent validation by a central computer. That is, a digital key 
provides access to the car per se, with no external authorization required or desired. With 
a "digital key", authorization is performed locally onboard the rental car by the access 
controller. Whipp et al. also does not teach a "digital key". Whipp et al., like Murakami 
et al., teach that each car must have a data link to a central computer for validation and 
authorization (see paragraphs 0025-0029, 0050-0053, 0061, 0072-0073). Such a data link 
is not necessary or desired when a "digital key" is used. 



09/652,159 (00280647AA) 




5 



Despite these teachings of Whipp et al., the Office Action erroneously asserts that 
Whipp et al. teaches a "key generating system..." and a "key return system...". Whipp et 
al. does not teach digital keys and does not teach any means or system for generating or 
returning digital keys. The sections of Whipp et al. identified in the Office Action as 
5 teaching these features instead teach methods for authenticating clients over the data link 
between the cars and the central computer. Wholly absent from Whipp et al. is any 
disclosure of a digital key generating system or a digital key return system. Whipp et al. 
does teach the use of electronic pass keys in paragraph 0063, but pass keys are not digital 
keys, and are not generated by the management system. Accordingly, the rejections of 

10 claims 1-10 are erroneous for this additional reason and must therefore be withdrawn. 

Regarding claim 8, Murakami et al. does not teach a digital key comprising car ID 
and user ID signed by a management system. Murakami et al. teach that only the user ID 
and PIN are used to provide the client with access to the car (see col. 11, lines 24-67). 

Regarding claim 9, Murakami et al. does not teach or suggest invalidation of a 

15 digital key. Murakami et al teach the use of a user ID, not a digital key. Also, Murakami 
et al. does not teach that the client returns an invalidated digital key. Murakami et al. 
instead teach that the central computer invalidates the clients ID. 

Regarding claim 10, Murakami et al does not teach or suggest that a digital key 
can store car status information. Col. 8 lines 24-64 (identified by the Examiner) instead 

20 teach that state of charge (SOC) or other state information can be sent to the central 
computer through the data link. Also, this section of Murakami et al. teach a selection 
process for matching cars with clients based on the SOC. 

With respect to claim 11, the Office Action erroneously asserts that Whipp et al. 
teach in paragraphs 0050-0056 the step of "creating a digital key... with a digital 

25 signature of the reservation server" and the step of "downloading the digital key to a 
portable storage device...". However, paragraphs 0050-0056 don't describe any sort of 
digital key or car access system. These paragraphs instead describe data communication 
between car and central computer (0050), components of the rental system (0051), leases 
and authorization (0052), components of car system (0053), software in the car (0054), 

30 car sensors (0055), and the car computer interface (0056). Wholly absent from Whipp et 
al. entirely and specifically from paragraphs 0050-0056 is any teaching or suggestion to 
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create a digital key or to use a digital key with a digital signature. Instead of a digital key, 
Whipp et al. teach the use of a data link between the car and the central computer for 
authorization (see paragraphs 0061, 0072 and 0073). Whipp et al. in paragraph 0063 
describes an electronic "pass key", but this pass key is not a digital key, is not "created by 
the reservation server", and does not have a "digital signature of the reservation server". 
Whipp et al. therefore fail to meet the limitations of claim 1 1 identified by the Examiner, 
and therefore the rejection of claims 11-19 must be withdrawn. 

Murakami et al. also fail to meet these limitations of claim 11 (as correctly noted 
by the Examiner), and so Murakami et al. cannot make up for the deficiencies of the 
Whipp et al. reference. No conceivable combination of Murakami et al. and Whipp et al. 
can produce the present invention set forth in claim 11. 

Regarding claim 15, Whipp et al does not in any way teach or suggest computing 
the hash of a car renters PIN, combining the hashed PIN with car and renter ID, and 
digitally signing the result. Whipp et al. in fact does not teach any of these steps.' The 
paragraphs identified in the Office Action have nothing to do with the limitations of 
claim 15. Murakami et al. also do not teach the steps of claim 15. Therefore, the rejection 
of claim 15 is in error. 

The rejections of claims 16, 17 and 18 are also erroneous for separate reasons. 
Specifically, regarding claim 16, neither Murakami et al. or Whipp et al. teach that the 
car can check the validity of a digital key. Regarding claim 17, neither Murakami et al 
nor Whipp et al. teach the step of the access controller in the car invalidating the digital 
key or generating a return packet and appending the return packet to the digital key. 
Regarding claim 18, neither Murakami et al. nor Whipp et al. teach the step of verifying 
the signature on the return packet. 

In view of the foregoing, it is respectfully requested that the application be 
reconsidered, that claims 1-19 be allowed, and that the application be passed to issue. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local telephone 
number listed below to discuss any other changes deemed necessary in a telephonic or 
30 personal interview. 
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A provisional petition is hereby made for any extension of time necessary for the 
continued pendency during the life of this application. Please charge any fees for such 
provisional petition and any deficiencies in fees and credit any overpayment of fees for 
the petition or for entry of this amendment to Attorney's Deposit Account No. 50-2041 
5 (Whitham, Curtis & Christofferson P.C.). 
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Michael E. Whitham 
Reg. No. 32,635 
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